Aminet 15/Aminet 15 - Nov 1996.iso/Aminet/docs/hyper/ZCD.lha/Listino/Reviews/GameSmith

Text File | 1996-06-17 | 16.2 KB | 316 lines

===========================================================================
                   REVIEW: GameSmith Development System
                             By:  Dave Haynie
===========================================================================

PRODUCT NAME:

    GameSmith Development System

BRIEF DESCRIPTION:

    A development system for writing video games.  For use with C and
    Assembler (versions included).  Provides high performance APIs for
    display, animation, and other game related programming.

AUTHOR/COMPANY INFORMATION:

    Oregon Research
    16200 S.W.  Pacific Highway
    Suite 162
    Tigard, OR 97224

MACHINE USED FOR TESTING:

    Amiga 3000/25, A3640
    16 MB Fast RAM
    2 MB Chip RAM
    Internal HD floppy
    Quantum 500 MB HD, SCSI
    CDC Wren 750 MB HD, SCSI
    44MB Syquest, SCSI
    NEC CD-ROM, SCSI
    Kickstart 40.60 and WB 40.42.
    oMniBus display system
    CTX 17" monitor

===========================================================================

ON WRITING GAMES

    Like many people, I began my computer career with games.  The first
computer game I played was a version of the classic "NIM", running on an HP
Desktop calculator (which originally cost more than a loaded A4000 does
today).  Not coincidentally, I also programmed my first games on this
machine, then later via dial-up account to a big CDC Cyber 72 computer.
Games at this level were meant to be played on a teletype of some kind,
they were written in BASIC, and they were very, very simple.

    My world changed in 1977 when my best friend bought one of the first
PET systems.  Here was not only a more powerful BASIC than on the CDC, but
it was on a screen!  I started messing around with games on the PET, then
two years later I bought my own computer (an Exidy Sorcerer, I've never
exactly followed the pack) and managed to sell four games to Creative
Computing Software.  These were BASIC/Assembler combinations, and were
distributed on cassette tape.

    Lots of things have changed since then.  The computer games of today
are several generations beyond these early games, and the best of them are
coded by some of the world's best programmers.  They're typically written
in fast assembly language, based on libraries of fine-tuned assembly code
and programming models, secret to each game company, developed over years
of games programming.

    On the non-professional side of things, programmers write games in
various languages, though BASIC is still, about twenty years after it first
gained popularity, a popular language for games programming.  But like
the games, BASIC has changed quite a bit.  Early BASIC was like assembly or
C language, in that it had only general purpose functions; if you wanted to
draw a circle on the screen, you wrote a routine to draw a circle.  In
today's AMOS, BlitzBasic, and a few others, things are completely
different.  BASIC comes with a wide variety of graphics functions,
including animation routines, collision detection, drawing routines,
scale/rotate functions, mouse and joystick inter- faces, etc.  There are
compilers that speed up the generated code and allows a stand-alone version
to be released.  And most modern BASICs come with a set of object editors,
to make drawing and animating very easy.

ENTER C/ASSEMBLER

    So, one might well ask, how could C or Assembler seriously be
considered for writing games?  Either you're playing, and write in BASIC,
or you hunker down, write a killer set of graphics routines, and turn pro.

    Until recently, that's probably just how it was for most people.  But
thanks to the GameSmith Development System, from Oregon Research, there is
now an alternative road to take.  The GameSmith system provides
sophisticated routines for display control, animation, collision detection,
timing, and other essential elements of any video game.

    GameSmith comes compressed on three floppy disks.  Via the standard
Amiga installer, it loads the various components of the system onto your
hard disk: the GameSmith linker library, includes for C and assembler, the
CITAS object animation tool, some examples, a tutorial, and optionally, a C
compiler (a special version of Obvious Implementations' DICE), and an
assembler (a special version of HiSoft's DevPac3), and of most interest,
the GameSmith library.  GameSmith can be used with most other C compilers
or standard Amiga assemblers.  As of this writing, it does not come with
the full set of Amiga include files, only because in the absence of
Commodore, there was no way to officially licence the include files.

DISPLAY AND GRAPHICS

    The first thing you'll need in any game is a window and, usually, some
kind of background.  GameSmith handles a variety of displays: Intuition
Window, Intuition Screen, or custom "take over the display" displays.
Custom displays are based on the Amiga's graphics.library.  They support
double buffering, smooth scrolling over a large bitmap, multiple viewports,
"parallax" viewports (scrolling with smooth wraparound), and even AGA
features.  User-define copper lists can be added, too.  The kind of display
is up to the programmer; GameSmith functions unrelated to display control
don't care about the kind of display.  There's even a GameSmith function
that identifies the type of Amiga chipset, so the display can be tailored
to the system in use.

    Once you have a display, the next step is to put something into it.  An
IFF/ILBM image from disk is easily loaded into an existing bitmap, or a new
bitmap sized to the image on load.  For double buffer support, the same
image can automatically go into two bitmaps.  The bitmap can be encrypted
for security (see below).

    Simplified blitter functions allow images to be blitted into a
background, optionally saving or restoring the background as necessary.
Single pixels can be set, complemented, and tested.  Colors can be set
individually, or by whole palette.

    A nice set of "vector" routines calculates coordinates of the best line
between any two points in a display.  While you can use this to draw lines,
it's just as useful for moving things along a straight line.

ANIMATION AND CITAS

    The Animation system is the high point of GameSmith, and the piece that
takes from being "a good idea" to "something really cool".  As an
experienced Amiga programmer, I wouldn't have a real problem doing most of
the other GameSmith functions myself, though GameSmith certainly does quite
a few of the tricky bits for you.  The Animation system is so slick,
though, it would take months if not years of programming animations on the
Amiga before you had something going nearly as well.  And, of course, the
GameSmith system is general purpose, you get to reuse it for any new game.

    The main point of the animation system is to automate the movement of
objects across a playfield, and manage their interaction with each other
and with the playfield.  This is a very sophisticated setup, though.  An
object can be a simple animation, a set of individual pictures which, when
played one after another, form some kind of motion (though one-frame
animations are also allowed).  Fancier movements can be done using a
"complex animation", which groups different animation sequences as one
item.  For example, I might have a running character in my game.  He can
run left or right, maybe also jump or duck.  That can be represented as a
series of six animation sequences.  All the programmer need worry about is
telling the animation system which sequence applies at any given moment.

    Integral to the animation is CITAS.  CITAS is a user friendly,
style-guide compliant tool for editing animations, complex animations, and
various collision relationships.  It can save any work to disk in files
that can be loaded by the GameSmith library routines, or convert directly
to C or Assembler, to allow the data to be embedded in the game itself.

    While individual movement images must be drawn in a bitmap editor,
CITAS can aid in assembling the animation.  It can flip images horizontally
or vertically, and rotate them by 90 degree increments.  Each cell in an
animation can be shifted for smooth alignments, and animations can be
previewed.  Complex animations can be built from any defined simple
animations.

    Up to 32 collision types can be defined for each animation.  Once the
types are defined, interactions between the types (what collides with what)
can be defined.  For each frame of an animation, rectangles corresponding
to any of the collision types may be defined.  Collisions between object
and background may also be defined.

OTHER COOL FEATURES

    The GameSmith sound system can load an IFF 8SVX or raw sample from
disk, and automatically play it for you.  The sound data can be buffered in
fast RAM (only a small amount of chip RAM is needed), and it can be
automatically looped from any single loop point in the sample.  Volume and
period can be set, and various automatic fades can be defined; reasonable
period constants for five octaves worth of notes are defined in an include
file.  Each of the four Amiga sound channels can be driven individually.

    Timing is a big concern, especially if you aim to support Amigas from
the original A500, A1000, and A2000, through the latest 68060-accelerated
A3000s and A4000; roughly a 100:1 performance range on many operations.
The key is tying performance to a constant, the most common constant is the
vertical blank.  Every 1/60th of a second on NTSC systems, 1/50ths of a
second on PAL systems, a normal video "frame" has been displayed, and must
be restarted.  This is called the vertical blank, due to the fact that the
display is blanked during this period (that's why you don't see anything
beyond the active overscan area of a screen).  Many elements of the
GameSmith system, animation and sound, for example, are automatically based
on vertical blank.  Additional functions provide a count of elapsed
vertical blanks, and allow an arbitrary function to be called during the
vertical blank.

    GameSmith supports a simplified joystick input function, which can
return the button and direction settings of a digital joystick in either
port.  For mouse or analog joysticks, you'll have to use AmigaOS functions
(or hardware banging, if that's your perferred method) directly.

ADDITIONAL TOOLS

    Unlike some BASIC systems, GameSmith is not completely stand-alone.
You will need a bitmap editor, such as Deluxe Paint, for creating
backgrounds, ANIMs, and other graphic objects (of course, ANIMs can be
created from bitmaps in CITAS).  For professional work, this is reasonable;
a real bitmap editor is much more flexible than any of the tiny editors
you'll find in most BASIC systems.

    Similarly, for sound you're going to need some way of creating effects,
music, or anything else that's going to play in a game.  An 8-bit audio
sampler and waveform editor is probably your best bet for building custom
sound effects.

PROFESSIONAL CONCERNS

    The first professional question to ask is, "could I use GameSmith for a
commercial game".  You certainly can.  The development system, obviously,
is copyrighted software and may not be given out.  The run-time system, the
bits of the GameSmith library that are compiled into your game, however,
have no listed restrictions at all.  This is a very nice attitude, and
definitely what professionals expect.  Some compiled BASIC systems restrict
their run-time systems to some extent, and course uncompiled BASIC can't be
distributed at all.

    Another concern is the integrity of your program and its artwork.  When
you have external images, animations, and sounds, you may not want users
taking these for their own programs.  GameSmith provides some help here.
You can lock an animation, such that other programs can't load it, and you
can check to make sure no alternate animation was substituted.  Animation
files are always encrypted; the "Save Anim Final" function in CITAS does
this, preventing any re-load back into CITAS.  IFF ILBM and 8SVX files can
also be encrypted on disk, and they'll be automatically decrypted by the
proper key when loaded.  The encryption functions are provided, but can be
replaced if desired.  While these might not fend off a determined cracker
with cryptographic experience, they're more than enough to dissuade most
users.

THE HELP BUTTON

    A valid concern of any programmer is the availability of technical
support for a new programming interface.  The first line of defense is, of
course, the included manual, and the 354 page GameSmith manual is fairly
complete.  In the usual fashion, the manual details the use of each
subsystem (Display, Animation, CITAS, Sound, and Utilities), then details
each specific GameSmith function.

    Another included resource is the set of include files themselves.  Much
like the normal Amiga include files, the GameSmith include files are
commented.  I have found this kind of commenting extremely valuable,
especially once you're started to understand the programming system and
getting into more detailed work.

    Finally, there's technical support from Oregon Research themselves.
When you return the registration card, you're entitled to 90 days of free
support via letter, phone, FAX, or email.  After the 90 day period, you can
still get free support via letter.  If you want more, for a nominal fee
Oregon offers two lifetime support programs which include phone, FAX, and
email support, a newsletter, access to their BBS, and optionally, free
incremental upgrades.  Obviously, their support is intended for the
GameSmith system itself, not C/Assembly programming or general AmigaOS
questions.

    While the GameSmith system can be considered stand-alone (assuming you
can track down some C or assembler include files, the Fred Fish CD-ROM
series is a good place for these), you will need the standard set of
programmer's documentation on the AmigaOS itself.  GameSmith doesn't
attempt to replace what the AmigaOS does well already, it's more of an
addition to it.  So you'll still use Amiga routines for memory allocation,
some disk I/O, etc.

MY GAME

    I went into this thinking, "hey, a BASIC-like game library for C, I'll
crank out a quickie game to go along with this review".  Well, I did start
writing a game, and I have made real progress.  But GameSmith isn't as
quick and dirty as your typical BASIC, and that's a good thing, really.
Because, as it turns out, GameSmith is far more powerful and considerably
faster than any BASIC I've played around with.

    So my game's not accompanying this review.  Hopefully I'll have time to
finish it, stay tuned to AmigaReport for news.  GameSmith is certainly fun
to work with, and the idea of writing something that can approach
professional quality is invigorating.  If you don't get there, it's your
idea, your artwork, etc.  that's sub-par, it's not likely to be GameSmith
in the way.

THE BOTTOM LINE

    The GameSmith Development System is an excellent way to get into game
development.  While it might not hit the performance levels of the best
custom routines used by the top game authors, it's probably close enough
for most purposes.  There's certainly a learning curve here, you're not
going crank out Lemmings on your first day with the system.  But you could
eventually write something like Lemmings with it.

    Of course, nothing's perfect.  I did get an Enforcer hit, apparently
when a GameSmith program closes down.  This should be harmless.  The
GameSmith system is an evolving thing at present, so there's a good chance
this will be fixed in future releases.

    While the animation system is excellent, the sound system is a bit
lacking.  While it's certainly possible to build an 8SVX file that plays a
tune, some support for converting MOD or MIDI files would be real useful.
Simple tunes could can represented with several short loops and a table of
pitch and duration values, but constructing this by hand would be tedious.

    The bottom line is that GameSmith is a real good idea, though perhaps
not for everyone.  It's usually harder, though by no means impossible, to
learn C or Assembler, even as a first language, rather than BASIC.  Well
written assembler will push a system as fast as it's capable of being
pushed, as long as the algorithms don't get in the way.  With a good
compiler like SAS or DICE, C code can approach the efficiency of Assembler,
and if nothing else, good C code is more maintainable than most BASIC or
Assembler, and it's a marketable skill.